iT邦幫忙

2022 iThome 鐵人賽

DAY 2
0
Security

備考 CISSP 敗部復活 雜草談 系列 第 2

天啊!評鑑跟測試怎麼跟我知道的很不同 ... (上)

  • 分享至 

  • xImage
  •  

寫在開始之前

筆者在第三方ISO 17025的專業測試實驗室工作超過15年的時間,但在準備及考CISSP時發現原來我理解的測試方法跟考試大綱中提到的觀點很多都相似卻不相同,在準備過程中才知道原來要做好評鑑跟測試不只是要注意到 驗證&確認 (V&V) 就好,還有其他相關細節也要一起注意才行,真的是魔鬼藏在細節裡。

從這開始

安全評鑑與測試 (Security assessment and test) 是CISSP 中Domain 6的範疇,但筆者認為這只是乘數而已,被乘數則是非Domain 6以外的其他各個Domain。

[十萬個WHY]

  1. 請問什麼是被乘數跟乘數呢??
    • 被乘數乘以乘數等於
      • 被乘數 跟 積的單位 是相同的
        • 如果「積」的單位是「元」,「被乘數」的單位就必須是「元」
        • [舉例] 一串葡萄50元,請問5串葡萄是多少錢?
          • 算式就會是:50(元)X5(串)=250(元)
  2. 為什麼這麼說呢?
    因為筆者在準備CISSP的過程中始終覺得,每個Domain拆開來唸之後跟做題的感覺一直連結不起來,但是當筆者使用上面的思考架構重新審視跟作答相關題目後就有恍然大悟的感覺出現。

那安全評鑑與測試,這章到底在講什麼? 為什麼要做?武功的核心心法是啥?

|無腦| 就是在做安全評鑑跟安全測試
|目的| 確認實施控制措施的有效性符合性
|心法| 查驗、訪談、測試

安全評鑑

安全評鑑,以NIST SP 800-53 R4 定義而言是指 安全控制評鑑 (SCA),意思是

  • 確定該控制措施是否有被正確執行
  • 可依照預期方式操作的程度, 產生出足以滿足用於資訊系統或組織安全性要求的結果

[無腦說法] 安全評鑑有時候又會被稱為安全評估,主要是從英文單詞 Security assessment 翻譯過來的關係

參考資料

安全評鑑的種類大致可分為以下三大類

  1. 第一方稽核
    • 通常泛指單位內部稽核或稱之為自評
  2. 第二方稽核
    • 通常泛指單位外部稽核,例如: 客戶來做稽核
  3. 第三方稽核
    • 由獨立單位做的稽核

細部又可概分為以下幾種 ...

  • SOC maturity assessment
    • 評鑑SOC運作及其成熟度
  • Security Assessment (安全評估)
    • 大方向的資安評估
  • Compliance auditing (符合性規範評估)
    • 以法遵合規為主的評估,例如: ISO或NIST
  • Operational auditing (運營評估)
    • 稽核是否依照企業組織運營規範所做的評估
  • Risk assessment (風險評鑑)
    • 以風險為導向的評估
  • Vulnerability Assessment (脆弱性評估)
    • 使用特定自動化工具或手法識別出資訊系統的漏洞
      • [應用] 財務系統 是否符合PCI DSS合規性規範
      • [應用] OWASP 十大漏洞的掃瞄
  • Penetration Test (滲透測試)
    • 由熟練的從業人員進行的良好手動滲透測試,可以揭示受控環境中不太明顯的漏洞,這種漏洞會導致現實世界中的重大失誤或問題發生。
    • 分為以下常見的三種分類
      • Red Team (紅隊)
        • 攻擊為主
      • Blue Team (藍隊)
        • 防守為主
      • Purple Team (紫隊)
        • 攻防一體

# 貼布

  1. 合規相關規範的評估也可由技術手段去輔助或達成
  2. 滲透測試中以藍隊及紫隊的評估比較有用
  3. [實務上] 建議先做一般的資安健檢後再做脆弱度評估或滲透測試,原因是如果直接去做滲透測試而得到一百多頁的失效 (Fail) 缺失結果, 該雇員可能會被辭退,或者因為組織內部已經有合規問題存在而造成即使做完滲透測試後也無法做到完善的改正措施。
  4. 並非多數企業都有SOC,有部分企業組織是以內部稽核代替資安評鑑

[十萬個WHY]

Q: 請問在安全評鑑中很常看到 C&A,A&A,V&V 名詞,請問這些指的是什麼?

A:

  • Verification and Validation (V & V)
    • 驗證跟確認
    • 內部: 驗證規格是否正確
    • 外部: 確認是否有滿足客戶需求
  • Certification and Acceditation (C&A)
    • 取證跟認可
    • 由獨立第三方確認特定產品或過程是否符合特定的產業標準後核發的許可證明
  • Assess and Authorize (A&A)
    • Assess: 指的是安全控制評鑑
    • Authorize: 授權
      • 流程:
        • 實施安全控制評鑑
        • 心法: 查驗、訪談、測試) 確保滿足有效性及符合性
        • 產出評鑑報告
        • 由主管單位授權讓其上線

[十萬個WHY]

Q: 請問資訊部門(MIS)的同事每次都可以直接幫同事安裝軟體,請問他們申請的難道不是永久授權嗎?
A: 這題就留給看倌自行去查找答案囉

那評鑑或測試報告的種類有哪些或者是否有固定格式呢?

  1. 第一方及第二方:
    • 沒有特定的格式,純粹看企業組織自己訂定的為主
  2. 第三方
    • 考試大綱 6.4 提到的是 SOC

[十萬個WHY]

Q: 請問什麼是SOC報告?

A: 服務組織控制 (SOC) 報告,又分為 SOC 1、2,3,由美國註冊會計師協會 (AICPA) 建立的框架,用於報告組織內所採用的內部控制設計。

SOC報告或種類 內容或對象 耗時 受眾對象
SOC 1 以財務系統為主 X 受限對象
SOC 2 以資訊系統為主 X 受限對象
SOC 3 SOC 2 Type II的摘要版 X 面向大眾開放
Type I 文件審查(各說各話) 90 天 SOC 1/ SOC 2
Type II 文件審查+實地審查一段時間 180天 SOC 1/ SOC 2/ SOC 3

SOC1 報告

作為財務報告內部控制 (ICFR) 計畫的關鍵元素。這些特定的擔保主要提供給客戶,用以遵循沙賓法案 ( Sarbanes-Oxley,SOX) 之規範。

SOC2 報告

針對企業組織之Security,Availability,Process Interity,Confidentiality 
(安全/ 可用/ 程序完整性/ 機密性)及(或) Privacy (隱私) 
等領域的控制評估

SOC3 報告

SOC2 Type II 的摘要版,鮮少透露出技術細節的內容,面向大眾的服務報告。通常很適合用來做市場行銷相關運用。

參考資料:

[十萬個WHY]

Q: 上面提及了安全評鑑有很多很多,那請問是否有大家可當作依歸的共同準則呢?

A: 當然有囉,那就是資訊技術安全評估共同準則 (Common Criteria for IT Security Evaluation),ISO15408,簡稱CC,是資訊安全性的架構,電腦系統的使用者可以在安全標的檔案當中,標示安全機能需求(Security Functional Requirements,SFR)及安全保障需求(Security Assurance Requirement,SAR)也可從系統的保護剖繪(Protection Profiles,PP)中取得這些資料。

參考資料 -- Common Criteria wikipedia

[謎之音] 又不是在玩角色扮演遊戲,但怎麼唸下來有各式各樣的角色還有他們各自的屬性要去熟悉,還要記的清楚牢固才行。

角色 全名 角色描述
TOE Target of Evaluation 廠商送來檢驗的資訊產品,簡稱待測物或DUT (Device Under Test)
ST Security Target 第三方驗證的檢驗標準,屬於行業標準,通常標準是由廠商自己訂定
PP Protection Profile 範本,提供給Security Target 做為參考使用
CCTL Common Criteria Testing Lab 提供CC 檢驗服務的實驗室機構

Q: 那請問CCTL 是依循什麼樣的基準在做查驗呢?
A: 當然是依照評估保證級別 (Evaluation Assurance Level,EAL)囉!!

評估保證級別 (Evaluation Assurance Level,EAL),
通常是以數值方式呈現,每一個級別會對應到一組預先定義好的安全保障需求(SAR),這些安全保障需求會涵蓋到產品開發的全部過程及存在一定的嚴謹程度。通常,數字越大(例如: EAL6)則代表檢驗過程是更加嚴謹,但這不代表這類的待測物是相對較安全的。

引用自評估保障級別

方面 EAL 已測試(Tested) 已檢查(Checked) 已查看(Reviewed) 有設計(Designed) 已做過設計驗證 (Design Verification) 時間(月)
Formally (正式) 7 X . . . X
Semi-formally (半正式) 6 X . . . X
Semi-formally (半正式) 5 X . . X . 18~24
Methodically (有條理) 4 X . X X . 12~16
Methodically (有條理) 3 X X . . .
Strucurally (有結構) 2 X . . . . 4~6
Functionally (有功能) 1 X . . . . 2~3

# 貼布

  • EAL 7: 最嚴謹的檢驗方式,具有學術水準或以數學理論為基礎的檢驗方式。
  • EAL 4: 產品基於高凝聚力低耦合架構的方式開發設計

[十萬個WHY] 請問什麼是高凝聚力低耦合?

  • 高凝聚力: 簡單的說就是願意為共同目標一起來努力
    • 這其實也是用來評估程式好壞的另一個準則,會去查看相同或類似的功能有沒有聚集在一起
  • 低耦合: 指的是模組與模組間的相依性關係,或者是大家很熟的颱風的藤原效應

參考資料:

小結

每天規律地念書,目標就在不遠處。 因為這個主題的資料量太大了,決定切開成上下集. 下集還在整理中.
待續 ..


上一篇
你的PDCA,不是我的PDCA?
下一篇
天啊!評鑑跟測試怎麼跟我知道的很不同 ... (下)
系列文
備考 CISSP 敗部復活 雜草談 35
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言